\section{Disadvantages of our technique}

Perhaps the most obvious disadvantage of our technique is that the
size of the code will more than double.  The debugging version of the
function body must implement the same functionality as the
non-debugging version, but in addition to that functionality, it must
also contain code for communicating with the debugger.  Furthermore,
since fewer optimizations are applied to the non-debugging version,
even without the code for communication, the debugging version would
be larger than the non-debugging version.

While the additional code will impact the memory footprint of the
system, we do not think it will have any negative influence on
caching.  The two versions of the body are kept separate, and the same
version is typically executed repeatedly.

Feedback on draft versions of this paper indicate that many readers
are worried about the possibility of the behavior of the different
versions of the function body described in
\refSec{sec-two-body-versions}.  This worry is based on experience,
as this situation is common, especially with implementations of
programming languages other than \commonlisp{}.  As we see it, there
are two possible causes for such difference in behavior:

\begin{enumerate}
\item A defect in the compiler can result in native code that does not
  correspond to the semantics of the source code, and the resulting
  code can be different in the different versions.
\item The compiler is exploiting undefined or unspecified behavior,
  probably in order to improve performance of the resulting code, and
  it exploits such behavior in different ways in the two different
  versions.
\end{enumerate}

We briefly addressed the first cause in \refSec{sec-introduction}, by
specifically targeting application programming, assuming that the
compiler is essentially free of defects.

The second cause was addressed in \refSec{sec-sicl-features}, where we
indicated that the \sicl{} system does not intend to take advantage of
undefined situations that will introduce any such differences in
application behavior.

Finally, the fact that the technique proposed in this paper is
incompatible with the way most \commonlisp{} systems work, makes it
unlikely that existing systems will be able to use it.  We are
convinced, however, that our technique will represent a major
advantage in terms of productivity for the application programmer.
